Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

31장. HTTPS는 어디에서 끝나는가 — TLS 종료의 이해

이 장에서 말하고자 하는 것

우리는 사용자가 도메인을 입력해
DNS를 거쳐 서버에 도달하는 흐름까지 왔다.

이제 다음 질문이 남는다.

https://api.example.com 의 그 "s" 는
어디에서 시작하고 어디에서 끝나는가?

이 장은 그 답을 다룬다.

핵심 키워드는

TLS 종료 (TLS Termination)

이다.

1. HTTPS는 무엇을 하는가

HTTPS는 HTTP에 보안을 더한 프로토콜이다.

  • 통신 내용을 암호화 해서 도청을 막고
  • 서버가 진짜 그 서버임을 검증 한다

이 두 가지를 동시에 하는 표준이 TLS다.

HTTP + TLS = HTTPS

2. TLS 핸드셰이크 — 매우 간단히

사용자가 서버에 처음 HTTPS로 연결하면
다음 흐름이 일어난다.

1. 사용자: 안녕, 너 누구야?
2. 서버: 내 인증서 받아 (공개키 포함)
3. 사용자: (인증서를 신뢰할 수 있는지 검증)
4. 둘이 한 번만 쓸 키를 만든다
5. 이 키로 이후 모든 데이터를 암호화

핵심은 4번이다.

진짜 데이터는 “한 번만 쓰는 키” 로 빠르게 암호화된다
인증서는 그 키를 안전하게 만들기 위한 도구다

3. 인증서가 하는 일

인증서는 서버의 신분증이다.

여기에는 다음이 들어 있다.

  • 도메인 이름 (예: api.example.com)
  • 공개키
  • 발급 기관(CA)의 서명
  • 유효 기간

브라우저는 미리 신뢰 가능한 CA 목록을 갖고 있다.

서명을 그 목록의 CA 키로 검증해 통과하면
“이 서버는 진짜다” 라고 판단한다.

4. TLS는 어디에서 끝낼 수 있는가

HTTPS 통신은 어딘가에서 한 번은
풀린(decrypted) 상태 가 되어야 한다.

서버가 요청을 읽으려면 평문이 필요하기 때문이다.

이 푸는 지점이

TLS 종료 지점

이다.

AWS에서는 세 군데 중에서 고를 수 있다.

사용자
  ↓ HTTPS
[① CloudFront]
  ↓ HTTPS or HTTP
[② ALB]
  ↓ HTTPS or HTTP
[③ EC2 / ECS]

각 지점에 인증서를 둘 수 있다.

5. 옵션 ① 엣지에서 종료 — CloudFront에서

사용자 ─HTTPS→ CloudFront ─HTTP→ ALB ─HTTP→ ECS

CloudFront 단계에서 푼다.

  • 사용자와 가까운 곳에서 핸드셰이크해 응답이 빠르다
  • 내부 구간은 HTTP라 처리가 가볍다

내부망이 AWS 안에 있고 신뢰 가능하다는 전제다.

6. 옵션 ② LB까지 HTTPS — ALB에서 종료

사용자 ─HTTPS→ CloudFront ─HTTPS→ ALB ─HTTP→ ECS

CloudFront와 ALB 사이도 HTTPS로 묶는다.

  • 내부 트래픽이 외부 네트워크를 일부 지나갈 때 안전하다
  • 인증서가 두 곳에 필요하다 (CloudFront · ALB)

운영에서 가장 일반적으로 사용하는 방식이다.

7. 옵션 ③ End-to-End — 서버까지 HTTPS

사용자 ─HTTPS→ CloudFront ─HTTPS→ ALB ─HTTPS→ ECS

서버까지 전 구간 암호화한다.

  • 가장 보안이 강하다
  • 인증서 관리가 가장 복잡하다
  • 처리 비용이 가장 크다

규제 산업(금융 · 의료)이나
민감 데이터를 다루는 서비스에서 쓴다.

8. 어디에서 종료해야 할까

판단 기준은 단순하다.

대부분 서비스   → ②번 (ALB에서 종료)
민감 데이터    → ③번 (End-to-End)
정적 콘텐츠만   → ①번 (CloudFront에서 종료)

핵심은

사용자 ~ 우리 인프라 입구 구간은 무조건 HTTPS

이고

내부 구간을 어디까지 HTTPS로 묶을지는 데이터 민감도로 결정

한다는 점이다.

9. 우리 서비스에서

이 책에서 만들 구조는 옵션 ② 다.

사용자 ─HTTPS→ CloudFront ─HTTPS→ ALB ─HTTP(내부 VPC)→ ECS

이유:

  • 보편적이다
  • 인증서 관리가 두 곳으로 제한된다
  • 내부 VPC 통신은 보안 그룹으로 통제 가능하다

10. 직접 확인해보기 — CLI

서버의 인증서 보기

openssl s_client -connect api.example.com:443 -servername api.example.com < /dev/null

응답에 인증서 정보가 들어 있다.

subject=CN = api.example.com
issuer =CN = Amazon, OU = Server CA 1B, O = Amazon, C = US

인증서의 유효 기간

echo | openssl s_client -connect api.example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

notBefore=Mar  1 00:00:00 2025 GMT
notAfter =Mar  1 23:59:59 2026 GMT

이 두 명령은 운영 중에
“내 인증서가 살아 있나” 를 가장 빠르게 확인하는 방법이다.

11. 코드로는 이렇게 생겼다 — Terraform

ALB에 HTTPS 리스너를 다는 모양이다.

resource "aws_lb_listener" "https" {
  load_balancer_arn = aws_lb.main.arn
  port              = 443
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
  certificate_arn   = aws_acm_certificate.main.arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}

certificate_arn 이 가리키는 인증서가
다음 장 ACM에서 만들 인증서다.

12. 이렇게 쓰면 망한다 — 안티패턴

안티패턴 1. HTTP 그대로 운영한다

http://api.example.com → 그대로 노출

브라우저가 경고하고, 검색 순위도 떨어진다.

운영 서비스는 무조건 HTTPS

안티패턴 2. HTTP 요청을 HTTPS로 안 보낸다

http://... 으로 온 요청을 그대로 받으면
사용자 일부는 평문으로 통신한다.

ALB 또는 CloudFront 에서

80 → 443으로 redirect

을 반드시 켠다.

안티패턴 3. 자체 서명 인증서로 운영한다

self-signed certificate

브라우저가 막는다. 사용자에게 “위험” 경고가 뜬다.

운영은 반드시 CA에서 발급한 인증서를 쓴다.
AWS에서는 ACM이 무료로 제공한다.

안티패턴 4. 인증서 만료를 모니터링하지 않는다

만료 하루 전에 알아채면 늦다.

ACM은 자동 갱신을 지원하지만
DNS 검증이 깨지면 갱신이 실패할 수 있다.

만료 30일 전부터 알람을 건다

13. 한 줄로 정리

HTTPS는 어딘가 한 곳에서 풀려야 하고,
그 지점을 어디에 둘지가 곧 보안 설계의 한 축이다

14. 이 장의 핵심 정리

  1. HTTPS는 HTTP + TLS이고, 암호화와 서버 검증을 함께 한다.
  2. TLS 종료 지점은 CloudFront · ALB · 서버 중 한 곳이다.
  3. 일반 서비스는 ALB에서 종료하는 ②번이 가장 흔하다.
  4. 민감 데이터는 End-to-End로 서버까지 HTTPS를 유지한다.
  5. HTTP는 443으로 리다이렉트하고, 자체 서명 인증서는 운영에 쓰지 않는다.
  6. 인증서 만료는 자동 갱신과 함께 알람으로 감시한다.